The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Error			Sep 26, 2025 0:42am

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage
• Provide comprehensive feedback

Code Quality & Best Practices ✅

Positive aspects:

• Code follows established TypeScript conventions with proper typing
• Good use of structured logging with logger() calls
• Proper error handling with custom error classes extending ActorError
• Consistent naming conventions (camelCase for variables/functions)
• Good separation of concerns between different modules

Areas for improvement:

• Some TODOs remain in comments (e.g., packages/rivetkit/src/manager/router.ts:289-290)
• Missing JSDoc documentation for public APIs

Potential Bugs & Issues 🔍

High Priority:

1. packages/rivetkit/src/manager/router.ts:289-290 - Empty name field in getForId call:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause issues with actor lookup validation.

2. packages/next-js/src/mod.ts:12-13 - Async params destructuring:

   const fetchWrapper = async (request: Request, { params }: { params: Promise<{ all: string[] }> }) => {
     const { all } = await params;

   This pattern suggests compatibility with Next.js 15's async params, but should be verified for backward compatibility.

Medium Priority:
3. packages/rivetkit/src/manager/router.ts:135-136 - JSON parsing without error handling:

connParams ? JSON.parse(connParams) : undefined,
authData ? JSON.parse(authData) : undefined,

Should wrap in try-catch blocks to handle malformed JSON.

4. packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:28-29 - Memory buffering warning:

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This could cause memory issues with large request bodies in serverless environments.

Performance Considerations ⚡

Concerns:

1. Memory buffering (actor-http-client.ts:29) - Full request buffering could be problematic in memory-constrained serverless environments
2. Synchronous JSON parsing - Multiple instances of JSON.parse() without async handling could block the event loop
3. WebSocket connection management - Complex proxy setup might have latency implications

Recommendations:

• Implement streaming request bodies for serverless compatibility
• Consider implementing request size limits
• Add connection pooling for HTTP requests where applicable

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON headers without validation (router.ts:135-136)
2. Header injection potential - Headers are copied wholesale in buildGuardHeadersForHttp() without sanitization
3. WebSocket proxy security - Complex proxy logic could have security implications if not properly validated

Recommendations:

• Validate and sanitize all user-provided headers
• Implement size limits on request bodies and headers
• Add input validation for JSON parsing operations

Test Coverage 📊

Observation: Cannot assess test coverage without running the test suite, but the presence of test infrastructure in the router suggests testing is considered.

Recommendations:

• Ensure new serverless functionality has corresponding tests
• Test error scenarios (malformed JSON, oversized requests)
• Test WebSocket proxy functionality under various network conditions

Specific Technical Feedback

packages/next-js/src/mod.ts:

• The disableServer: true flag correctly prevents duplicate server startup
• URL reconstruction logic looks correct for serverless routing
• Consider adding validation for the all parameter array

packages/rivetkit/src/common/versioned-data.ts:

• Solid implementation of data versioning with proper migration support
• Good error handling for version mismatches
• Consider adding version validation bounds

scripts/nuke-cache.sh:

• Comprehensive cache clearing script
• Good safety checks with directory existence validation
• Consider adding dry-run mode for safety

Summary

This is a well-structured serverless implementation that follows the project's coding standards. The main concerns are around error handling for JSON parsing, memory management for request buffering, and some incomplete TODOs. The architecture appears sound for serverless deployment.

Recommended actions before merge:

1. Fix the empty name field in router.ts:290
2. Add try-catch blocks around JSON.parse() calls
3. Address the memory buffering TODO or add size limits
4. Complete remaining TODOs or create issues for them

• chore(core): reimpl reconnect logic #1310
• fix(core): fix getters on ActorConn proxy #1311
• chore(core): simplify connection handling & fix graceful reconnect #1309
• chore(core): clean up token configs #1298
• fix(core): clean up websocket protocol handling #1297
• chore(core): add token & optional headers to client #1296
• feat: serverless #1288 👈 (View in Graphite)
• 09-16-fix_next-js_fix_example_for_next-js #1250
• fix(core): fix missing ManagerDriver impls #1308
• main

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• merge queue - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

This stack of pull requests is managed by Graphite. Learn more about stacking.

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/actor@1288

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/cloudflare-workers@1288

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/core@1288

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/db@1288

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/framework-base@1288

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/next-js@1288

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/react@1288

pnpm add https://pkg.pr.new/rivet-dev/rivetkit@1288

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/sql-loader@1288

commit: a1ed010

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback via GitHub comment

Overview

This PR implements serverless support for RivetKit, primarily focused on Next.js integration. The changes introduce a new @rivetkit/next-js package and modify the core router to handle serverless environments better.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing
• Follows established project conventions (camelCase, proper imports)
• Good use of structured logging with logger() calls
• Proper error handling patterns extending ActorError
• Well-organized code structure

Areas for improvement:

• Missing JSDoc documentation for public APIs (particularly toNextHandler)
• Some TODO comments left unresolved

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:291 - Empty name field:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause issues with actor lookup validation and should be addressed.

2. packages/rivetkit/src/manager/router.ts:136-137 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully.

Medium Priority:

3. packages/next-js/src/mod.ts:12 - Async params destructuring pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   This suggests Next.js 15 compatibility but should be verified for backward compatibility.

4. URL reconstruction logic in Next.js handler could be brittle - consider validation of the all parameter array.

Performance Considerations ⚡

Concerns identified:

1. Memory buffering (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints.

2. Request handling efficiency: The serverless handler creates new Request objects which could be optimized.

Recommendations:

• Implement streaming for large request bodies
• Add request size limits for serverless environments
• Consider connection pooling where applicable

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing: Multiple locations parse JSON without proper error handling (router.ts:136-137)
2. Header propagation: Headers are copied wholesale in buildGuardHeadersForHttp() without sanitization
3. WebSocket proxy complexity: The complex proxy logic could have security implications

Recommendations:

• Add try-catch blocks around all JSON.parse() calls
• Implement header sanitization and validation
• Add input size limits to prevent DoS attacks

Test Coverage 📊

Observations:

• No new test files were added for the serverless functionality
• The Next.js integration lacks test coverage
• WebSocket proxy functionality should have comprehensive error scenario tests

Recommendations:

• Add unit tests for toNextHandler function
• Test error scenarios (malformed JSON, oversized requests)
• Add integration tests for the Next.js serverless workflow

Architecture & Design 🏗️

Positive aspects:

• Clean separation of concerns with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Good abstraction of serverless routing logic

Considerations:

• The versioned data handler changes appear sound with proper migration support
• Cache clearing script is comprehensive and well-structured

Specific Technical Feedback

packages/next-js/src/mod.ts:

• Consider adding input validation for the all parameter
• The URL reconstruction logic is correct but could benefit from error handling

packages/rivetkit/src/common/versioned-data.ts:

• Excellent implementation of data versioning with proper error handling
• Migration logic is robust and well-designed

scripts/nuke-cache.sh:

• Comprehensive cache clearing with good safety checks
• Consider adding a dry-run mode for extra safety

Summary

This is a solid serverless implementation that follows the project's coding standards. The main concerns are around error handling for JSON parsing, memory management for request buffering, and some incomplete TODOs.

Priority fixes needed:

1. Fix empty name field in router.ts:291
2. Add try-catch blocks around JSON.parse() calls
3. Address memory buffering TODO or implement size limits
4. Add comprehensive test coverage

Recommended before merge:

• Complete or create issues for remaining TODOs
• Add basic test coverage for serverless functionality
• Consider backward compatibility implications

The architecture and approach are sound, making this a valuable addition to RivetKit's serverless capabilities.

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback via GitHub comment

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging)
• Good use of logger() calls with structured logging patterns
• Proper error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (see issues section below)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:291 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups.

2. packages/rivetkit/src/manager/router.ts:136-137 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully.

Medium Priority:

3. packages/next-js/src/mod.ts:12 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified.

4. packages/next-js/src/mod.ts:16 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments.

Performance Considerations ⚡

Concerns identified:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints and should be prioritized.

2. Request object creation - The Next.js handler creates new Request objects which could be optimized for better performance.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider request/response caching strategies where appropriate

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137)

2. Header propagation (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks.

3. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation
• Add input size limits to prevent DoS attacks
• Consider implementing a whitelist for allowed headers

Test Coverage 📊

Observations:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks test coverage entirely
• WebSocket proxy functionality should have comprehensive error scenario tests
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns

Technical Implementation:

packages/next-js/src/mod.ts - Solid serverless integration:

• URL reconstruction logic is correct but could use input validation
• Proper HTTP method support across GET, POST, PUT, PATCH, HEAD, OPTIONS
• Clean integration with RivetKit's fetch handler

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and conventions. The core functionality is sound, but there are several areas requiring attention before merge.

Critical fixes needed:

1. Resolve empty name field in router.ts:291
2. Add error handling for JSON parsing operations
3. Address memory buffering TODO or implement size limits

Recommended improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization
• Add JSDoc documentation for public APIs
• Complete remaining TODO items or create issues for them

Overall Assessment: The implementation provides solid serverless support for RivetKit with good architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework.

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:291 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups. The API should either provide the name or handle this case properly.

2. packages/rivetkit/src/manager/router.ts:136-137 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully. Malformed JSON could cause the entire request to fail.

Medium Priority:

3. packages/next-js/src/mod.ts:12 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified for users on older Next.js versions.

4. packages/next-js/src/mod.ts:16 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries to prevent blocking.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137, engine/actor-driver.ts:311-312)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

4. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• WebSocket proxy functionality has no test coverage for error scenarios
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions and error states
• Add tests for the versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns and error handling

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Specific Technical Feedback

Engine Actor Driver Changes:

• The serverless start endpoint implementation looks solid
• Good use of Server-Sent Events for health monitoring
• Proper async handling throughout

Router Improvements:

• Better CORS handling and request routing
• Comprehensive WebSocket proxy implementation
• Good error handling patterns

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Resolve empty name field in router.ts:291 - this could cause runtime failures
2. Add error handling for all JSON parsing operations to prevent crashes
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:291 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups. The API should either provide the name or handle this case properly.

2. packages/rivetkit/src/manager/router.ts:136-137 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully. Malformed JSON could cause the entire request to fail.

Medium Priority:

3. packages/next-js/src/mod.ts:12 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified for users on older Next.js versions.

4. packages/next-js/src/mod.ts:16 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries to prevent blocking.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137, engine/actor-driver.ts:311-312)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

4. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• WebSocket proxy functionality has no test coverage for error scenarios
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions and error states
• Add tests for the versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns and error handling

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Specific Technical Feedback

Engine Actor Driver Changes:

• The serverless start endpoint implementation looks solid
• Good use of Server-Sent Events for health monitoring
• Proper async handling throughout

Router Improvements:

• Better CORS handling and request routing
• Comprehensive WebSocket proxy implementation
• Good error handling patterns

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Resolve empty name field in router.ts:291 - this could cause runtime failures
2. Add error handling for all JSON parsing operations to prevent crashes
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

View job

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback via GitHub comment

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:292 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups. The API should either provide the name or handle this case properly.

2. packages/rivetkit/src/manager/router.ts:137-138 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully. Malformed JSON could cause the entire request to fail.

3. packages/rivetkit/src/drivers/engine/actor-driver.ts:311-312 - Additional unprotected JSON parsing:

   const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
   const authData = authDataRaw ? JSON.parse(authDataRaw) : undefined;

Medium Priority:

4. packages/next-js/src/mod.ts:13 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified for users on older Next.js versions.

5. packages/next-js/src/mod.ts:17 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries to prevent blocking.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:137-138, engine/actor-driver.ts:311-312)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

4. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• WebSocket proxy functionality has no test coverage for error scenarios
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions and error states
• Add tests for the versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns and error handling

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Specific Technical Feedback

Engine Actor Driver Changes:

• The serverless start endpoint implementation looks solid
• Good use of Server-Sent Events for health monitoring
• Proper async handling throughout

Router Improvements:

• Better CORS handling and request routing
• Comprehensive WebSocket proxy implementation
• Good error handling patterns

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Resolve empty name field in router.ts:292 - this could cause runtime failures
2. Add error handling for all JSON parsing operations to prevent crashes
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:292 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups. The API should either provide the name or handle this case properly.

2. packages/rivetkit/src/manager/router.ts:137-138 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully. Malformed JSON could cause the entire request to fail.

3. packages/rivetkit/src/drivers/engine/actor-driver.ts:311-312 - Additional unprotected JSON parsing:

   const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
   const authData = authDataRaw ? JSON.parse(authDataRaw) : undefined;

Medium Priority:

4. packages/next-js/src/mod.ts:13 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified for users on older Next.js versions.

5. packages/next-js/src/mod.ts:17 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries to prevent blocking.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:137-138, engine/actor-driver.ts:311-312)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

4. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• WebSocket proxy functionality has no test coverage for error scenarios
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions and error states
• Add tests for the versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns and error handling

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Specific Technical Feedback

Engine Actor Driver Changes:

• The serverless start endpoint implementation looks solid
• Good use of Server-Sent Events for health monitoring
• Proper async handling throughout

Router Improvements:

• Better CORS handling and request routing
• Comprehensive WebSocket proxy implementation
• Good error handling patterns

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Resolve empty name field in router.ts:292 - this could cause runtime failures
2. Add error handling for all JSON parsing operations to prevent crashes
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

KIT-288 Serverless runner integration

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Address review comment about disabling endpoints in serverless mode
• Provide comprehensive feedback

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:354 - Unprotected JSON parsing in WebSocket handler:

   params = JSON.parse(paramsRaw);

   This should be wrapped in try-catch to handle malformed JSON gracefully.

2. packages/rivetkit/src/manager/gateway.ts:100 - Unprotected JSON parsing:

   const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;

3. packages/rivetkit/src/drivers/engine/actor-driver.ts:328 - Unprotected JSON parsing:

   const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;

4. packages/rivetkit/src/actor/router.ts:89, 180 - Multiple unprotected JSON parsing instances:

   const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;

All these JSON parsing operations could cause the entire request to fail if malformed JSON is provided.

Medium Priority:

5. packages/next-js/src/mod.ts:13 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified.

6. packages/next-js/src/mod.ts:17 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:354, gateway.ts:100, engine/actor-driver.ts:328, actor/router.ts:89,180)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Review Comment: Disabling Endpoints in Serverless Mode 🎯

The review comment correctly identifies that when the serverless driver is enabled, other endpoints should be disabled. Currently, the code adds /start and /health endpoints when serverlessActorDriverBuilder is present, but it doesn't disable the existing management endpoints like:

• GET / - Welcome endpoint
• GET /actors - List actors
• PUT /actors - Get or create actors
• POST /actors - Create actors
• Test endpoints (.test/inline-driver/call)
• Inspector endpoints (/inspect)

Recommendation: Wrap the existing endpoint definitions in a conditional check to disable them when running in serverless mode:

if (!serverlessActorDriverBuilder) {
  // Existing endpoints like GET /, GET /actors, etc.
}

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• Missing integration tests for the Next.js serverless workflow
• No error scenario testing for JSON parsing failures

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test the new versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true and disableActorDriver: true flags for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Add error handling for all JSON parsing operations to prevent crashes
2. Address the reviewer's concern about disabling non-serverless endpoints when in serverless mode
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Address review comment about endpoint disabling
• Provide comprehensive feedback

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Critical Issues ⚠️

1. Review Comment Issue - Endpoint Access Control (HIGH PRIORITY)
The review comment at packages/rivetkit/src/manager/router.ts:444 correctly identifies that all other endpoints should be disabled when serverless driver is enabled. Currently, when serverlessActorDriverBuilder is present (serverless mode), the code only adds /start and /health endpoints but still exposes:

• GET / (root endpoint)
• GET /actors (actor listing)
• PUT /actors (get or create actors)
• POST /actors (create actors)
• Test endpoints (.test/inline-driver/*)
• Inspector endpoints (/inspect/*)

This is a security and architectural concern - serverless environments should have a minimal attack surface and controlled endpoint exposure.

2. Unprotected JSON Parsing (HIGH PRIORITY)
Multiple locations parse JSON without proper error handling, which could cause crashes:

• packages/rivetkit/src/manager/gateway.ts:100: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
• packages/rivetkit/src/drivers/engine/actor-driver.ts:328: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
• packages/rivetkit/src/manager/router.ts:354: params = JSON.parse(paramsRaw);

3. URL Reconstruction Vulnerability (MEDIUM PRIORITY)
In packages/next-js/src/mod.ts:17:

newUrl.pathname = all.join('/');

The all parameter from Next.js params is used directly without validation, potentially allowing path injection attacks.

Performance Concerns ⚡

1. Memory Buffering Issue (CRITICAL for Serverless)
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29:

// TODO: This buffers the entire request in memory every time. We
// need to properly implement streaming bodies.
const reqBody = await actorRequest.arrayBuffer();

This is particularly problematic in serverless environments with memory constraints and could cause cold start issues.

2. Request Object Creation Overhead
The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

Security Concerns 🔒

1. Header Propagation Without Sanitization
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69 - Headers are copied wholesale without validation, potentially allowing header injection attacks.

2. Missing Input Validation

• No size limits on request bodies or parameters
• Path segments in Next.js handler aren't validated
• JSON parsing without error boundaries

Test Coverage 📊

Critical gaps:

• No test files added for serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• Missing integration tests for serverless workflow
• No tests for error scenarios (malformed JSON, invalid paths)

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true and disableActorDriver: true flags
• Good integration with existing RivetKit patterns
• Versioned data handler is well-implemented with proper migration support

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support
• Proper configuration flags for serverless mode

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches
• Clean separation of serialization concerns

scripts/nuke-cache.sh - Well-structured cache management:

• Comprehensive coverage of JavaScript build cache directories
• Good safety checks and colored output

Recommendations

Critical fixes needed before merge:

1. Implement endpoint access control for serverless mode - When serverlessActorDriverBuilder is present, disable or restrict access to non-essential endpoints
2. Add try-catch blocks around all JSON.parse() operations to prevent crashes
3. Address memory buffering TODO or implement request size limits for production use
4. Add input validation for path segments in Next.js handler

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization
• Add request size limits to prevent DoS attacks
• Complete remaining TODO items or create issues for future work

Medium priority:

• Add JSDoc documentation for public APIs
• Consider backward compatibility for Next.js versions
• Implement dry-run mode for cache clearing script

Summary

This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. The core functionality is sound, but the critical issue identified in the review comment about endpoint access control must be addressed before merge. The versioned data handling and routing improvements are particularly well-implemented.

Overall Assessment: With the identified security and access control issues addressed, this will be a valuable addition to RivetKit's deployment options.

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Address review comment about endpoint disabling
• Provide comprehensive feedback

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Critical Issues ⚠️

1. Review Comment Issue - Endpoint Access Control (HIGH PRIORITY)
The review comment at packages/rivetkit/src/manager/router.ts:93-97 correctly identifies that all other endpoints should be disabled when serverless driver is enabled. Currently, when serverlessActorDriverBuilder is present (serverless mode), the code only adds /start and /health endpoints via addServerlessRoutes(), but when it's not present, addManagerRoutes() exposes:

• GET / (root endpoint)
• GET /actors (actor listing - lines 150-221)
• PUT /actors (get or create actors - lines 223-274)
• POST /actors (create actors - lines 276-313)
• Test endpoints (.test/inline-driver/* - lines 343, 371, 431)
• Inspector endpoints (/inspect/* - lines 499-514)

This is a security and architectural concern - serverless environments should have a minimal attack surface and controlled endpoint exposure. The current implementation means ALL these management endpoints are still accessible even in serverless mode.

2. Unprotected JSON Parsing (HIGH PRIORITY)
Multiple locations parse JSON without proper error handling, which could cause crashes:

• packages/rivetkit/src/manager/gateway.ts:100: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
• packages/rivetkit/src/drivers/engine/actor-driver.ts:328: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
• packages/rivetkit/src/manager/router.ts:406: params = JSON.parse(paramsRaw);

3. URL Reconstruction Vulnerability (MEDIUM PRIORITY)
In packages/next-js/src/mod.ts:20:

newUrl.pathname = all.join('/');

The all parameter from Next.js params is used directly without validation, potentially allowing path injection attacks.

Performance Concerns ⚡

1. Memory Buffering Issue (CRITICAL for Serverless)
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:24-26:

// TODO: This buffers the entire request in memory every time. We
// need to properly implement streaming bodies.
const reqBody = await actorRequest.arrayBuffer();

This is particularly problematic in serverless environments with memory constraints and could cause cold start issues or memory exhaustion.

2. Request Object Creation Overhead
The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

Security Concerns 🔒

1. Header Propagation Without Sanitization
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:61-63 - Headers are copied wholesale without validation:

for (const [key, value] of actorRequest.headers.entries()) {
    headers.set(key, value);
}

This could potentially allow header injection attacks or information leakage.

2. Missing Input Validation

• No size limits on request bodies or parameters
• Path segments in Next.js handler aren't validated
• JSON parsing without error boundaries

Test Coverage 📊

Critical gaps:

• No test files added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• Missing integration tests for serverless workflow
• No tests for error scenarios (malformed JSON, invalid paths)

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true and disableActorDriver: true flags
• Good integration with existing RivetKit patterns
• Versioned data handler is well-implemented with proper migration support

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Proper configuration flags for serverless mode

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support (lines 36-62)
• Good error handling for version mismatches (lines 41-45, 52-55)
• Clean separation of serialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Well-structured cache management:

• Comprehensive coverage of JavaScript build cache directories (lines 33-53)
• Good safety checks and colored output
• Consider adding a dry-run mode for extra safety

Summary

This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. The core functionality is sound, but the critical issue identified in the review comment about endpoint access control must be addressed before merge.

Critical fixes needed before merge:

1. Implement endpoint access control for serverless mode - When serverlessActorDriverBuilder is present, ensure addManagerRoutes() is not called or its endpoints are disabled
2. Add try-catch blocks around all JSON.parse() operations to prevent crashes
3. Address memory buffering TODO or implement request size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Medium priority:

• Add JSDoc documentation for public APIs
• Consider backward compatibility for Next.js versions
• Implement dry-run mode for cache clearing script

Overall Assessment: With the identified security and access control issues addressed, this will be a valuable addition to RivetKit's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

View job

Claude finished @MasterPtato's task —— View job

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Address the review comment about disabling endpoints in serverless mode
• Provide comprehensive feedback

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Critical Issues ⚠️

1. Review Comment Issue - Endpoint Access Control (HIGH PRIORITY)
The review comment at packages/rivetkit/src/manager/router.ts:93-97 correctly identifies that all other endpoints should be disabled when serverless driver is enabled. Currently, when serverlessActorDriverBuilder is present (serverless mode), the code only adds /start and /health endpoints but still exposes:

• GET / (root endpoint)
• GET /actors (actor listing)
• PUT /actors (get or create actors)
• POST /actors (create actors)
• Test endpoints (.test/inline-driver/*)
• Inspector endpoints (/inspect/*)

This is a security and architectural concern - serverless environments should have a minimal attack surface and controlled endpoint exposure.

2. Unprotected JSON Parsing (HIGH PRIORITY)
Multiple locations parse JSON without proper error handling, which could cause crashes:

• packages/rivetkit/src/manager/gateway.ts:100: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
• packages/rivetkit/src/drivers/engine/actor-driver.ts:328: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
• packages/rivetkit/src/manager/router.ts:406: params = JSON.parse(paramsRaw);

3. URL Reconstruction Vulnerability (MEDIUM PRIORITY)
In packages/next-js/src/mod.ts:20:

newUrl.pathname = all.join('/');

The all parameter from Next.js params is used directly without validation, potentially allowing path injection attacks.

Performance Concerns ⚡

1. Memory Buffering Issue (CRITICAL for Serverless)
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:24-26:

// TODO: This buffers the entire request in memory every time. We
// need to properly implement streaming bodies.
const reqBody = await actorRequest.arrayBuffer();

This is particularly problematic in serverless environments with memory constraints and could cause cold start issues.

2. Request Object Creation Overhead
The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

Security Concerns 🔒

1. Header Propagation Without Sanitization
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:61-63 - Headers are copied wholesale without validation, potentially allowing header injection attacks.

2. Missing Input Validation

• No size limits on request bodies or parameters
• Path segments in Next.js handler aren't validated
• JSON parsing without error boundaries

Test Coverage 📊

Critical gaps:

• No test files added for serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• Missing integration tests for serverless workflow
• No tests for error scenarios (malformed JSON, invalid paths)

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true and disableActorDriver: true flags
• Good integration with existing RivetKit patterns
• Versioned data handler is well-implemented with proper migration support

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support
• Proper configuration flags for serverless mode

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches
• Clean separation of serialization concerns

scripts/nuke-cache.sh - Well-structured cache management:

• Comprehensive coverage of JavaScript build cache directories
• Good safety checks and colored output

Recommendations

Critical fixes needed before merge:

1. Implement endpoint access control for serverless mode - When serverlessActorDriverBuilder is present, disable or restrict access to non-essential endpoints
2. Add try-catch blocks around all JSON.parse() operations to prevent crashes
3. Address memory buffering TODO or implement request size limits for production use
4. Add input validation for path segments in Next.js handler

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization
• Add request size limits to prevent DoS attacks
• Complete remaining TODO items or create issues for future work

Medium priority:

• Add JSDoc documentation for public APIs
• Consider backward compatibility for Next.js versions
• Implement dry-run mode for cache clearing script

Summary

This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. The core functionality is sound, but the critical issue identified in the review comment about endpoint access control must be addressed before merge. The versioned data handling and routing improvements are particularly well-implemented.

Overall Assessment: With the identified security and access control issues addressed, this will be a valuable addition to RivetKit's deployment options.

Merge activity

• Sep 26, 7:06 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Sep 26, 7:06 AM UTC: CI is running for this pull request on a draft pull request (#1312) due to your merge queue CI optimization settings.
• Sep 26, 7:07 AM UTC: Merged by the Graphite merge queue via draft PR: #1312.